refactor(library-config): reorganize Linux process context by cataphract · Pull Request #2228 · DataDog/libdatadog

cataphract · 2026-07-10T16:49:08Z

What does this PR do?

This is 1/3 in the stacked process-context series.

It reorganizes the existing Linux process-context implementation without changing its behavior:

separates shared reader and writer logic into dedicated modules;
moves Linux-specific allocation, discovery, clock, and copy behavior behind platform modules;
introduces independent reader and writer Cargo features while preserving the existing Linux defaults at this layer;
adds platform-agnostic exports and retains the Linux compatibility path;
preserves the existing functionality exactly, including the edge cases and bugs addressed by the next PR.

Why?

This creates the module structure needed for additional operating systems without mixing a large code move with functional changes. Reviewers can evaluate the organization independently before the Linux implementation is updated and the new platforms are added.

Impact

There is no intended runtime behavior change. Linux remains the only supported implementation in this PR, and existing Linux callers retain the same behavior.

Validation

Validated independently at this commit with:

cargo check -p libdd-library-config --all-features;
cargo check -p libdd-library-config-ffi;
all-feature process-context tests;
reader-only process-context tests.

Stack

refactor(library-config): reorganize Linux process context #2228 — reorganize the Linux process context
fix(library-config): update Linux process context #2237 — update the Linux implementation
feat(library-config): add macOS and Windows process context #2238 — add macOS and Windows support

BREAKING CHANGE: moves ProcessContextSelfReader from the Linux-specific module to the platform-agnostic process-context API, while retaining the deprecated Linux compatibility path.

github-actions · 2026-07-10T16:51:27Z

📚 Documentation Check Results

⚠️ 844 documentation warning(s) found

📦 `libdd-library-config-ffi` - 578 warning(s)

📦 `libdd-library-config` - 266 warning(s)

Updated: 2026-07-14 23:06:00 UTC | Commit: b561139 | missing-docs job results

pr-commenter · 2026-07-10T16:51:36Z

Benchmarks

Comparison

Candidate

Candidate benchmark details

Baseline

Baseline benchmark details

github-actions · 2026-07-10T16:52:29Z

🔒 Cargo Deny Results

⚠️ 2 issue(s) found, showing only errors (advisories, bans, sources)

📦 `libdd-library-config-ffi` - 1 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:118:1
    │
118 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── (dev) libdd-common v5.1.0
      │   ├── libdd-common-ffi v37.0.0
      │   │   └── libdd-library-config-ffi v0.0.2
      │   └── libdd-library-config-ffi v0.0.2 (*)
      └── libdd-library-config v3.0.0
          └── libdd-library-config-ffi v0.0.2 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-library-config` - 1 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:46:1
   │
46 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     └── libdd-library-config v3.0.0

advisories FAILED, bans ok, sources ok

Updated: 2026-07-14 23:07:20 UTC | Commit: b561139 | dependency-check job results

datadog-prod-us1-6 · 2026-07-10T16:52:45Z

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 76.57%
• Overall Coverage: 74.50% (+0.05%)

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: 89a636d | Docs | Datadog PR Page | Give us feedback!}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 19438b34d4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

danielsn · 2026-07-10T18:40:17Z

+            let chunk_len = (len - offset).min(self.chunk_size);
+            let chunk_addr = addr.wrapping_add(offset);
+
+            // SAFETY: write asks the kernel to copy from chunk_addr. Invalid user memory is


Reading the man page, it seems like error detection may occur but I don't see where it is guaranteed? POSIX does not appear to require EFAULT at all.

We're only targeting Linux and macOS. Both Linux's and mac os man pages describe this return value.

danielsn · 2026-07-10T18:43:10Z

+        })
+    }
+
+    fn copy(&self, addr: *const u8, len: usize) -> Result<Vec<u8>, PipeCopyError> {


Does this function have SAFETY requirements?

The whole point of the function is that it should not generate a fault if attempting to read unmapped or otherwise inaccessible manner. So there is no safety contract that the caller must respect in order for the invocation of the function not to trigger UB.

I think this contract (copy won't fail even for unmapped addresses or unitialized memory) should be specified at the trait level, in the documentation of copy. It's not obvious for anyone who hasn't sufficient context (as demonstrated by Daniel's question)

danielsn · 2026-07-10T18:48:10Z

+            let chunk_addr = addr.wrapping_add(offset);
+
+            // SAFETY: write asks the kernel to copy from chunk_addr. Invalid user memory is
+            // reported as EFAULT or a short write without being dereferenced by Rust.


What are the semantics in the case of a short write

If there is a short write, then something interrupted the function after it's already written some data. It could have been interrupted, or it could have found an unreadable page.

But it turns out that, despite what the mac os man page says, write() always returns EFAULT upon encountering a fault, even if it's written something. This requires marking its error with pipe_dirty: true, which I'll do in a bit.

danielsn · 2026-07-10T18:59:36Z

+        }
+
+        // SAFETY: every byte was initialized by the pipe reads above.
+        unsafe { bytes.set_len(len) };


would it be safer to vec![0,len], or std::io::BorrowedBuf?

I answered a similar comment when this code was introduced (it was just moved in this PR): https://github.com/DataDog/libdatadog/pull/2176/changes/BASE..12ca390b7683b6efaeae6cf06078b26eaf41a3d9#diff-e3f807d69a162e59e2e82257164c7642090139e9d90f6be2fecde5205ead3636 :

What difference does it make if it's initialized with zeros or not? The read syscall writes directly into the buffer and it should fill it to capacity. And if it there was a bug and it didn't, zeros or uninitialized memory would be equally wrong (I'd probably even prefer uninitialized memory because it's more likely to be caught by MSan).

BorrowedBuf would indeed be a small improvement, but it doesn't appear to be stable.

The difference is that you would get rid of this unsafe get_len I believe. You initialize it with the right length from the beginning and just use it as a fixed-sized array [u8; N]. No need to uphold any safety condition anymore.

dd-octo-sts · 2026-07-10T19:12:53Z

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	86.15 MB	86.15 MB	+0% (+8.03 KB) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	7.88 MB	7.88 MB	0% (0 B) 👌

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.62 MB	10.62 MB	+0% (+160 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	97.40 MB	97.41 MB	+0% (+8.82 KB) 👌

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	25.54 MB	25.54 MB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	88.44 KB	88.44 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	185.33 MB	185.34 MB	+0% (+16.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	957.25 MB	957.26 MB	+0% (+10.35 KB) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.35 MB	8.35 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	88.44 KB	88.44 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	24.72 MB	24.72 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	49.21 MB	49.21 MB	-0% (-228 B) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	22.19 MB	22.19 MB	-0% (-512 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	89.82 KB	89.82 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	189.78 MB	189.77 MB	-0% (-8.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	945.93 MB	945.94 MB	+0% (+10.35 KB) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.46 MB	6.46 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	89.82 KB	89.82 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	26.54 MB	26.54 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	46.82 MB	46.82 MB	-0% (-200 B) 👌

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	76.96 MB	76.97 MB	+0% (+4.14 KB) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	8.81 MB	8.81 MB	0% (0 B) 👌

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	92.37 MB	92.38 MB	+0% (+3.27 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.72 MB	10.72 MB	+.03% (+3.79 KB) 🔍

ivoanjo · 2026-07-13T07:52:22Z

This is very cool, and I definitely want to give it a pass ASAP. Having said that, I'd like to request a change in the way we refer to this.

Specifically, at this time, we're not trying or proposing upstream any way of using the OTel process context and thread context specifications on macOS and Windows.

Thus I humbly request:

Let's drop the "otel" from the naming we use when we refer to macOS or Windows -- let's just call it "process context" and "thread context"
In any files that include macOS or Windows support, let's explicitly document that macOS and Windows support is not part of the spec and is an experimental datadog extension

My intent here is to give us fully the space to experiment and validate -- if this goes really well it will be great to fold it into the spec; but not confuse outside-Datadog folks, since the specs explicitly call out process context and thread context as being Linux-specific mechanisms for the time being.

ivoanjo · 2026-07-13T07:53:38Z

Furthermore (forgot to add to the above) -- not being yet tied to the spec gives us flexibility to go "Oh actually we want to do it another different way on Windows" (or macOS) while we're experimenting, whereas if we were folding this right away into the spec it'd be weird to flip-flop as we experiment.

cataphract · 2026-07-13T09:49:11Z

OK, I've renamed the PR and added a few comments. Note that this follows the specification to the extent that it can be followed. I's only the part that can only be implemented on Linux, the discovery mechanism, that differs. All the rest -- the data itself, how it's laid out, the update protocol, follows the spec.

ivoanjo · 2026-07-14T12:38:16Z

At this point, this PR is too big -- I humbly request that we break it down into smaller steps. E.g. first one with all changes for Linux, and then separate windows and macOS support.

With so many changes it'll be a lot of work to figure out what's only moving and what's actually changing.

cataphract · 2026-07-14T14:37:10Z

@ivoanjo I've split it into 3 commits. The first is just moves code around and has no change in the linux functionality. The second contains the updates I did to the linux implementation. Finally, the third adds windows and mac os. Hope this helps.

ivoanjo · 2026-07-14T15:53:54Z

I'd really like separate PRs -- I feel like we're creating a huge PR that will take a bunch of time to deliver, whereas small PRs have small steps that we can agree on and move quickly on.

ivoanjo · 2026-07-14T15:55:20Z

To be clear, I am aware that split PRs are a pain for the submitter -- yet that's exactly what I'm asking for here, I'm asking you to help us ship this fast by making it easier on the reviewers to move fast on it.

cataphract · 2026-07-14T17:52:21Z

As a reviewer, I'd rather have the three commits in one PR, since the reorganization and abstractions make more sense in light in the mac os/windows implementations in the later commits. But to each his own

yannham · 2026-07-16T09:25:24Z

@@ -0,0 +1,240 @@
+// Copyright 2026-Present Datadog, Inc. https://www.datadoghq.com/
+// SPDX-License-Identifier: Apache-2.0
+


Nit: add a short module description

yannham · 2026-07-16T09:27:18Z

+        })
+    }
+
+    fn copy(&self, addr: *const u8, len: usize) -> Result<Vec<u8>, PipeCopyError> {


I think this contract (copy won't fail even for unmapped addresses or unitialized memory) should be specified at the trait level, in the documentation of copy. It's not obvious for anyone who hasn't sufficient context (as demonstrated by Daniel's question)

yannham · 2026-07-16T09:28:48Z

+}
+
+#[cfg(target_os = "linux")]
+fn create_pipe() -> io::Result<(OwnedFd, OwnedFd, usize)> {


Should the return type be a proper struct instead of a triplet?

yannham · 2026-07-16T09:33:18Z

+
+// Re-exported for backwards compatibility.
+#[cfg(feature = "process-context-writer")]
+#[deprecated(note = "use libdd_library_config::otel_process_ctx directly")]


I would be inclined to ignore backward compatibility and just get rid of those. The process context implementation is rather recent, there's little to no code that uses the ProcessContext API directly outside of libadatadog to my knowledge, and even then, we control that code. Any opinion @ivoanjo ?

yannham · 2026-07-16T09:34:24Z

+
+pub(super) trait ProcessMemoryCopy: Sized {
+    fn new() -> io::Result<Self>;
+    fn copy(&self, addr: *const u8, len: usize) -> Result<Vec<u8>, PipeCopyError>;


Re copy: the contract should be clearly specified here.

yannham · 2026-07-16T09:35:57Z

+}
+
+#[derive(Debug)]
+pub(super) struct PipeCopyError {


Isn't this a bit Linux-specific (the pipe implementation)? Maybe it's just a minor naming issue, and this should be MemoryCopyError or sth. But it feels like Linux implementation is leaking a bit here.

yannham · 2026-07-16T09:39:37Z

+pub struct ProcessContextSelfReader {
+    pid: u32,
+    pub(in crate::otel_process_ctx) header_ptr: NonNull<u8>,
+    pipe: Cell<Option<PlatformCopyPipe>>,


Isn't this linux-specific as well? I think PlatformCopyPipe is only defined on Linux, right? In general I would expect this module to have a very simple copy interface -- basically ProcessMemoryCopy that guarantees fault-free copy, without talking about pipes or whatnot, which is an implementation detail.

Then either ProcessContextSelfReader should be parametrized by a Copier: ProcessMemoryCopy, or if that's too heavy, define a ProcessMemoryCopyImpl for each platform in a dedicated module, and import it unconditionally here.

yannham · 2026-07-16T09:41:40Z

+
+// SAFETY: the reader owns its copy pipe and only stores a process-global address. Cell keeps the
+// type !Sync, so the cached pipe cannot be used concurrently through shared references.
+unsafe impl Send for ProcessContextSelfReader {}


Same, for modularity purpose, we should probably require ProcessMemoryCopy to be Send, moving the burden to the platform-specific implementation. Maybe the implementation on Windows wouldn't use pipe but a totally different mechanism; it's hard for ProcessContextSelfReader to justify in advance that all implementations for ProcessMemoryCopy in the future will be Send.

yannham · 2026-07-16T09:58:30Z


 [features]
-otel-thread-ctx = []
+default = ["process-context-reader", "process-context-writer"]


I would not make process-context-reader the default. For now it seems quite specific to the PHP profiler.

yannham · 2026-07-16T10:00:30Z

@@ -0,0 +1,268 @@
+// Copyright 2026-Present Datadog, Inc. https://www.datadoghq.com/


I got quite confused by the fact that there's a top-level reader.rs file, but also submodules in a different reader/xxx subdirectory. Same for writer. Would you have anything against moving reader.s and writer.rs to respective mod.rs files in the corresponding subdirectories? We would have everything writer-related and reader-related at the same place.

yannham

(Sorry, I meant to approve - none of the comments above are blocking)

cataphract requested a review from a team as a code owner July 10, 2026 16:49

cataphract requested review from vpellan and removed request for a team July 10, 2026 16:49

cataphract changed the title ~~otel process ctx support on macos win~~ feat(library-config): support OTel process contexts on macOS and Windows Jul 10, 2026

chatgpt-codex-connector Bot reviewed Jul 10, 2026

View reviewed changes

Comment thread libdd-library-config/src/tracer_metadata.rs

Comment thread libdd-library-config/src/otel_process_ctx/reader/macos.rs Outdated

danielsn reviewed Jul 10, 2026

View reviewed changes

cataphract requested a review from a team as a code owner July 10, 2026 20:12

github-actions Bot added the ci-build label Jul 10, 2026

cataphract force-pushed the glopes/otel-process-ctx-macos-win branch from f1169de to f5eccae Compare July 11, 2026 18:57

cataphract changed the title ~~feat(library-config): support OTel process contexts on macOS and Windows~~ feat(library-config): support process contexts on macOS and Windows Jul 13, 2026

cataphract force-pushed the glopes/otel-process-ctx-macos-win branch from 9bd8dd1 to 011c154 Compare July 14, 2026 14:35

cataphract force-pushed the glopes/otel-process-ctx-macos-win branch from 011c154 to 1a04bb0 Compare July 14, 2026 17:56

github-actions Bot removed the ci-build label Jul 14, 2026

This was referenced Jul 14, 2026

fix(library-config): update Linux process context #2237

Open

feat(library-config): add macOS and Windows process context #2238

Open

cataphract changed the title ~~feat(library-config): support process contexts on macOS and Windows~~ refactor(library-config): reorganize Linux process context Jul 14, 2026

cataphract force-pushed the glopes/otel-process-ctx-macos-win branch from 1a04bb0 to e6af895 Compare July 14, 2026 18:20

refactor(library-config): reorganize Linux process context

89a636d

cataphract force-pushed the glopes/otel-process-ctx-macos-win branch from e6af895 to 89a636d Compare July 14, 2026 23:03

yannham reviewed Jul 16, 2026

View reviewed changes

yannham approved these changes Jul 16, 2026

View reviewed changes

		@@ -0,0 +1,240 @@
		// Copyright 2026-Present Datadog, Inc. https://www.datadoghq.com/
		// SPDX-License-Identifier: Apache-2.0

		@@ -0,0 +1,268 @@
		// Copyright 2026-Present Datadog, Inc. https://www.datadoghq.com/

Uh oh!

Conversation

cataphract commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Why?

Impact

Validation

Stack

Uh oh!

github-actions Bot commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📚 Documentation Check Results

📦 libdd-library-config-ffi - 578 warning(s)

📦 libdd-library-config - 266 warning(s)

Uh oh!

pr-commenter Bot commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmarks

Comparison

Candidate

Baseline

Uh oh!

github-actions Bot commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Cargo Deny Results

📦 libdd-library-config-ffi - 1 error(s)

📦 libdd-library-config - 1 error(s)

Uh oh!

datadog-prod-us1-6 Bot commented Jul 10, 2026 • edited by datadog-prod-us1-5 Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cataphract Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dd-octo-sts Bot commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Artifact Size Benchmark Report

Uh oh!

ivoanjo commented Jul 13, 2026

Uh oh!

ivoanjo commented Jul 13, 2026

Uh oh!

cataphract commented Jul 13, 2026

Uh oh!

ivoanjo commented Jul 14, 2026

Uh oh!

cataphract commented Jul 14, 2026

Uh oh!

ivoanjo commented Jul 14, 2026

Uh oh!

ivoanjo commented Jul 14, 2026

Uh oh!

cataphract commented Jul 14, 2026

Uh oh!

cataphract commented Jul 10, 2026 •

edited

Loading

github-actions Bot commented Jul 10, 2026 •

edited

Loading

📦 `libdd-library-config-ffi` - 578 warning(s)

📦 `libdd-library-config` - 266 warning(s)

pr-commenter Bot commented Jul 10, 2026 •

edited

Loading

github-actions Bot commented Jul 10, 2026 •

edited

Loading

📦 `libdd-library-config-ffi` - 1 error(s)

📦 `libdd-library-config` - 1 error(s)

datadog-prod-us1-6 Bot commented Jul 10, 2026 •

edited by datadog-prod-us1-5 Bot

Loading

cataphract Jul 10, 2026 •

edited

Loading

dd-octo-sts Bot commented Jul 10, 2026 •

edited

Loading